Role Based Access Control (RBAC) is a model for enforcing security policies with computers. In RBAC, users are assigned to roles and access control lists are specified in terms of roles. In RBAC, a role represents a job function within the context of a business or other organization with some associated semantics regarding the authority and responsibility conferred on the users assigned to the role. Very generally, an access control list is set of permissions associated with an object (e.g., a file or process in an operating system or a table in a relational database). An access control list specifies what operations can be performed on the object and who or what can perform those operations. For example, an access control list associated with a directory of a computer file system that stores customer invoices might specify that users assigned to the Accounting Role can read and write files stored in the directory.
By allowing access control lists to be specified in terms of roles, RBAC simplifies management of security policies. Access control lists do not need to be managed in terms of individual user identities and instead can be managed in terms of a fewer number of roles. Granting individual users permissions to perform operations on objects becomes a simplified matter of assigning users to the appropriate roles. For further description of RBAC, see e.g., “ANSI/INCITS 359-2004”, an ANSI/INCITS standard dated Feb. 3, 2004, the disclosure of which is hereby incorporated by reference. A copy of the standard is available via the Internet (e.g., currently at www.incits.org).
Unfortunately, RBAC is not suited to enforcing security policies that apply to all users regardless of their identity or the roles to which they are assigned. An example of such a security policy is: social security numbers retrieved from the database must be transmitted over encrypted network connections. This security policy is an example of application environment based security policy. Enforcement of an application environment based security policy depends not on the identity or the roles of the user interacting with the application, but on the state of the environment in which the user is interacting with the application. In the example application environment based security policy, permission to read social security numbers from the database depends not on the identity or role of the user that is interacting with the database application, but on whether the network connection between the user and the database application is encrypted.
One approach to enforcing application environment based security policies using RBAC is to assign users to roles and then selectively activate the roles for users depending on the detected state of the system environment. For example, the database application could detect whether a user is connected to the application via an encrypted network link and then activate a role assigned to the user that gives the user permission to access social security numbers. However, this approach is difficult to implement from the perspective of a security administrator. For example, a security administrator would have to ensure that all possible users are assigned to the role that provides permission to access social security numbers. Furthermore, this approach would require that each application that accesses social security numbers have logic for detecting the state of the system environment and logic for mapping system environment states to the roles that are to be selectively activated.
Based on the foregoing, there is a need for a more natural framework for enforcing application environment based security policies using role based access control.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.